Multitenancy refers to an architecture where multiple independent clients (instances of one or more applications) operate in a shared environment such as a cloud platform. A tenant may refer to a collection of users that share common access to an instance of a software application, resource, and/or the like. In some cases, a tenant may refer to a representation or instance of an organization or enterprise that has access to a multi-tenant application. A tenant may also refer to an application from among a plurality of applications competing for shared underlying resources. The multiple tenants may be logically isolated but physically integrated. For example, the degree of logical isolation may be complete isolation while the degree of physical integration may vary. When devices and services (i.e., edges) communicate with applications in cloud, a message oriented middleware may be required to handle the complexity of routing communications to and from cloud, while maintaining isolation between different tenants. For example, the message oriented middleware may include hardware and/or software for sending and receiving messages to and from a distributed system. Examples of message oriented middleware for cloud computing include RabbitMQ, ActiveMQ, Kafka, and the like, and messaging protocols used by message oriented middleware include Advanced Message Queuing Protocol (AMQP), MQ Telemetry Transport (MQTT), and the like.
For cloud based messaging services in a multi-tenant environment it is critical to maintain logical separation among the multiple tenants. For example, clients belonging to different tenants should be able to create topics with the same name without any conflicts or cross talk. As an example, a client of one tenant subscribing to a topic should not see messages from a client of another tenant publishing to a topic with the same name. Prevention of conflicts is usually achieved by providing different endpoints to different tenants. With different endpoints one could route the requests (publish/subscribe) to different physical or logical clusters of message brokers in the cloud. For example, different endpoints could be provided in different forms such as different top level domains or sub domains. However, in this case, a cloud provider must register for these domains and make sure that requests to these domains/subdomains are routed to appropriate logical or physical clusters. This requires significant overhead in terms of managing the domain registrations.
As another example, different endpoints could be provided via a path element in a uniform resource locator (URL). This avoids overhead of the previously mentioned approach, however, this only works for those protocols that support the notion of path elements in their URL. For example, AMQP allows a user to specify a host in URL as a path but MQTT does not provide that support. Accordingly, this approach is not universally applicable for all messaging protocols. Another way cloud providers can achieve multi tenancy is by asking users to include some headers in their payload to indicate the tenancy. But again, this only works for some protocols (e.g., AMQP) that support custom headers but not for those protocols that don't support custom headers (e.g., MQTT).
Furthermore, even after establishing tenancy through one or more of the above described means, a user must still authenticate a device or a service attempting to access the cloud by using one or more of a variety of mechanisms including, but not limited to, basic authentication (username/password), X.509 certificate based authentication, challenge-response authentication, and the like.
Throughout the drawings and the detailed description, unless otherwise described, the same drawing reference numerals will be understood to refer to the same elements, features, and structures. The relative size and depiction of these elements may be exaggerated or adjusted for clarity, illustration, and/or convenience.